Security Wine (бывший - DevSecOps Wine)

Security Guardrails

Существует термин, введённый Джейсоном Чаном, бывшим директором по информационной безопасности Netflix, который называется "безопасная асфальтированная дорога" (secure paved roads). Этот термин используется в контексте интеграции безопасности таким образом, чтобы она оставалась невидимой. Предположим, разработчики пишут код или администраторы деплоят ресурсы в облако, не осознавая, что делают это безопасно, не придерживаясь при этом множества руководящих принципов.

Звучит как сказка, но в настоящее время это всё чаще обсуждается в контексте реализации так называемых Security Guardrails. Это достаточно общий термин, в рамках которого разработчикам и администраторам по умолчанию предоставляются заведомо безопасные функции, классы, ресурсы и механизмы для повседневной работы. Например, вот авторы статьи предоставили разработчикам кастомные классы Terraform CDK для создания ресурсов RDS. Вместо того чтобы создавать RDS с множеством мисконфигураций, как это обычно происходит, разработчики могут воспользоваться классом DatabaseInstance, в котором уже встроены шифрование, ограничение публичного доступа и другие меры безопасности. Затем они передают класс на исполнение функции generate_databases, и безопасники ликуют.

Развивая данную концепцию, мы приходим к ситуации, когда внутренним пользователям предоставляются исключительно безопасные по умолчанию утилиты, сервисы, механизмы SSO, аутентификации и авторизации, где пользователь заведомо не может сделать что-то неправильно. Это противоречит подходу большинства вендоров, которые стремятся сделать запуск сервисов максимально простым, не зная всех особенностей каждого заказчика. Соответственно, это приводит к поддержке команды безопасности, которая создает Security Guardrails под нужды организации, делая их, при этом, простыми в эксплуатации. Такие команды безопасности обрели название Security Platform Engineers, статьей про которых мы тоже решили поделиться в продолжении повестки. В России развитие таких команд особенно заметно на фоне стремительно появляющихся AppSec платформ, разрабатываемых in-house (привет Альфа-Банк, VK, Yandex и другие).

Это действительно интересная ниша, где видится появление большого количества стартапов. Например, Semgrep даже сделали бесплатный курс про Secure Guardrails, где они объясняют своё видение их применения в контексте своего инструмента.

Zip Engineering

Enabling Security Guardrails: Infra as Code with CDK for Terraform

In this post, we describe how the Zip security team leveraged the Python CDK for Terraform (CDKTF) to enforce security guardrails for our AWS infrastructure. We provide example configurations and code to help other security teams build their own secure AWS…

www.tg-me.com/sg/DevSecOps Wine/com.sec_devops/611

4.9K viewsRustam Guseynov, Jul 31, 2024 at 05:59

Security Guardrails

Существует термин, введённый Джейсоном Чаном, бывшим директором по информационной безопасности Netflix, который называется "безопасная асфальтированная дорога" (secure paved roads). Этот термин используется в контексте интеграции безопасности таким образом, чтобы она оставалась невидимой. Предположим, разработчики пишут код или администраторы деплоят ресурсы в облако, не осознавая, что делают это безопасно, не придерживаясь при этом множества руководящих принципов.

Звучит как сказка, но в настоящее время это всё чаще обсуждается в контексте реализации так называемых Security Guardrails. Это достаточно общий термин, в рамках которого разработчикам и администраторам по умолчанию предоставляются заведомо безопасные функции, классы, ресурсы и механизмы для повседневной работы. Например, вот авторы статьи предоставили разработчикам кастомные классы Terraform CDK для создания ресурсов RDS. Вместо того чтобы создавать RDS с множеством мисконфигураций, как это обычно происходит, разработчики могут воспользоваться классом DatabaseInstance, в котором уже встроены шифрование, ограничение публичного доступа и другие меры безопасности. Затем они передают класс на исполнение функции generate_databases, и безопасники ликуют.

Развивая данную концепцию, мы приходим к ситуации, когда внутренним пользователям предоставляются исключительно безопасные по умолчанию утилиты, сервисы, механизмы SSO, аутентификации и авторизации, где пользователь заведомо не может сделать что-то неправильно. Это противоречит подходу большинства вендоров, которые стремятся сделать запуск сервисов максимально простым, не зная всех особенностей каждого заказчика. Соответственно, это приводит к поддержке команды безопасности, которая создает Security Guardrails под нужды организации, делая их, при этом, простыми в эксплуатации. Такие команды безопасности обрели название Security Platform Engineers, статьей про которых мы тоже решили поделиться в продолжении повестки. В России развитие таких команд особенно заметно на фоне стремительно появляющихся AppSec платформ, разрабатываемых in-house (привет Альфа-Банк, VK, Yandex и другие).

Это действительно интересная ниша, где видится появление большого количества стартапов. Например, Semgrep даже сделали бесплатный курс про Secure Guardrails, где они объясняют своё видение их применения в контексте своего инструмента.

BY Security Wine (бывший - DevSecOps Wine)